home *** CD-ROM | disk | FTP | other *** search
- Path: darkstar.prodigy.com!davidsen
- From: davidsen@tmr.com (bill davidsen)
- Newsgroups: comp.dcom.modems
- Subject: Re: Why USR Courier 33.6 SO SLOW: 2.0k/sec downloads?
- Date: 3 Jan 1996 22:51:07 GMT
- Organization: TMR Associates, Schenectady NY
- Message-ID: <4cf18r$181k@useneta1.news.prodigy.com>
- References: <951216.140830.9G7.rnr.w165w@zswamp.UUCP> <30d62c03.25136810@news.netwide.net> <4bhvcb$2c5@mips.pfalz.de> <DKB98r.4LJ@bokonon.ussinc.com>
- NNTP-Posting-Host: darkstar.prodigy.com
- Originator: davidsen@darkstar.prodigy.com
-
- In article <DKB98r.4LJ@bokonon.ussinc.com>,
- Stephen M. Dunn <stephen@bokonon.ussinc.com> wrote:
- | In article <4bhvcb$2c5@mips.pfalz.de> naddy@mips.pfalz.de (Christian Weisgerber) writes:
- | $No, it's not. The 33600 is the straight modem<->modem synchronous bit
- | $rate. Maximum throughput without compression is about 33600 / 8 *
- | $(244/(244+7)) * (62/63) = 4018cps.
- |
- | Christian, I take it that one of those two factors has to do with
- | packet overhead (that would presumably be the first one) but I
- | don't know about the second one, or any underlying assumption (such
- | as what protocol - LAP-M? Some MNP level?).
-
- The interesting thing is that for years I've been telling people to
- figure 8.3 bits/byte throughput with error correction, which might
- be easier to remember for most folks who haven't looked at the
- protocols. I use that as a starting point when determining if a
- connection has a problem or not.
- --
- -bill davidsen (davidsen@tmr.com)
- I will support laws and technology which limit what you are allowed
- to hear, if you will oppose laws and technology limiting what I am
- allowed to say.
-